「走れ！プロジェクトマネージャー！」

　世の中には、様々なプロジェクトが存在し、色々なプロジェクトマネージャーがそのプロジェクトを実施しています。今日もどこかで新しいプロジェクトが。。。
　ところで、その様々なプロジェクトは、どのように評価されているのでしょうか。建設物であれば、完成品を見るのでしょう。（余談：構造設計は、見る仕組みはあるのでしょうか）
　システム開発では、「要件通りに機能するか」を見ます。まずそれが一番大切。しかし、それはあくまで「プロジェクトの成果物」を評価しているのであって、「プロジェクトそのもの」を評価しているわけではありません。
　では、プロジェクトそのものは、どのように評価すれば良いのでしょうか。実はこれは、かなりいい加減（言い過ぎなら、ごめんなさい）な評価が多いように思います。

　「赤字ではなかった」、「○○万円儲かった」といったものが主流になるのだと思いますが、実は一番大切なものは、
１．「顧客（プロジェクトオーナー）視点で、良いものが出来たか」
２．「予定と実績の管理は、どうだったか。差分の理由と、その対応」
なのではないか、と考えています。

　１．顧客（プロジェクトオーナー）視点で、良いものが出来たか
　この視点は、かなり大切です。いくら我々が満足しても、顧客が不満足なプロジェクトは成功とは呼べません。また顧客の視点が欠けていると、扱いにくい成果物が出来上がってしまいます。「要件は満たしているが、不満足」といったものは、そういうことなのだと思います。顧客からすると、「確かに自分が言ったとおりに出来ているのだから納得はするけれども、もうちょっと何とかならないものなのか。」といった、不満が残ります。
　こういう不満を残さないためにも、こまめなレビューが必要ですし、要所要所で意識合わせを行うことも必要です。早めのズレは修正できますが、後からの修正は苦労と工数を要しますから。

　２．予定と実績の管理は、どうだったか。差分の理由と、その対応
　予定をきちんと立てないでスタートしてしまうプロジェクトがあります。もちろんやむを得ない事情があることもあります。ただ、だからといって「全く予定無し」でいくわけにはいきません。必ずどこかで、「分かる範囲の予定」を整理する必要があります。終わったら、実績と予定の突合を行い、何が出来て、何は出来ていなかったか、を見ることで、差分が分かりますし、差分の理由もはっきりします。
　その差分はなぜ発生したのか。仕様変更があったのか、あるいは何かのミスなのか、そのミスに対するリカバリはどうなのか、といったものです。
　仕様変更がないシステム開発プロジェクトは極めて稀です。あって当然とも言えます。だからこそ、小さい単位での把握が必要です。プロジェクトの評価は、予実の把握と言っても過言ではないと思います。
　こういう様々な矛盾を含めて、きちんとした評価と振り返りを行うことで、プロジェクトの成功確立は高まります。